Skip to content

Clean up output capture on .NET Core #78205

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 22, 2025
Merged

Clean up output capture on .NET Core #78205

merged 3 commits into from
Apr 22, 2025

Conversation

jaredpar
Copy link
Member

This cleans up how we handle output capture on .NET Core. This moves from a lot of mutable static static, that would break if tests ran in parallel, to instance state that uses locks to guard againtst concurrent runs.

This cleans up how we handle output capture on .NET Core. This moves from a lot of mutable `static` static, that would break if tests ran in parallel, to instance state that uses locks to guard againtst concurrent runs.
@jaredpar jaredpar requested review from a team as code owners April 18, 2025 18:21
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 18, 2025
@jaredpar
Copy link
Member Author

@dotnet/roslyn-compiler PTAL

@jaredpar jaredpar removed the untriaged Issues and PRs which have not yet been triaged by a lead label Apr 19, 2025
public interface IRuntimeEnvironment : IDisposable
{
(int ExitCode, string Output, string ErrorOutput) Execute(string[] args, int? maxOutputLength);
(int ExitCode, string Output, string ErrorOutput) Execute(string[] args);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously the maxOutputLength parameter was used to guard againts infinite loops, seemed useful but it's removed now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was only done on .NET Core though, not .NET Framework. I considered putting the same code path in .NET Framework but that guard hasn't gotten tripped anytime that I remember. Removing the guard means we will still get an exception in an infinite loop, just it will be an OOM exception. So decided to simplify here and remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw, I've seen that guard hit locally during development, I think.

@jaredpar jaredpar merged commit 9eb88c2 into dotnet:main Apr 22, 2025
28 checks passed
@jaredpar jaredpar deleted the eval3 branch April 22, 2025 19:07
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Apr 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants